Here are some frequently asked questions (and frequently given answers!) about NetBSD/alpha.
No. NetBSD/alpha requires the SRM Console firmware (used by OSF/1 and OpenVMS) to function. There are two main reasons for this: the console software is what's resposible for loading the operating system's primary bootstrap program, and the NT firmware's method of doing this is undocumented; and the firmware provides the PALcode for the system, which handles low-level memory management and interrupt handling details on a system-specific basis.
Other systems, such as the Alpha port of Linux, apparently do support systems which only have NT firmware. Because of the difficulty of making this work, it is unlikely to happen for NetBSD/alpha in the near future unless someone with a vested interest in having it work actually writes the code to do it.
At this time, only the ZLXp-E1 frame buffer is supported by the NetBSD/alpha X11 server. Hopefully that will change in the near future.
If you try to set up a Digital UNIX (formerly DEC OSF/1) system as an NFS server containing NetBSD diskless root partitions, you'll run into a problem: Digital UNIX does not properly handle NetBSD device nodes. Apparently, to ease the transition from 16-bit to 32-bit device nodes, Digital added run-time conversion code to convert from the old device node format to the new format. Unfortunately, this causes the device nodes as seen by a diskless NetBSD to be garbage. The only solutions to this are binary or source modifications to the Digital UNIX kernel, so, for most users, the easiest solution is to simply not use a Digital UNIX system as the server for NetBSD diskless clients.
# mount the file system mount /dev/sd1a /mnt # install the bootstrap programs cp /usr/mdec/boot /mnt sync sync ./installboot /mnt/boot /usr/mdec/bootxx /dev/sd1a
You must be in single-user mode to do this, or have the kernel security mode set to 0 if you are in multi-user mode. If you're making an already-mounted disk bootable or reinstalling boot blocks on your root disk, you will not have to (and/or may not be able to) remount it, so this example may not be correct for all situations.
Note that NetBSD/alpha can only boot from disks' a partitions, and that the a partition of a bootable disk must start at the beginning of the disk. A bootable disk's a partition must also contain a NetBSD/alpha kernel (otherwise, you won't have anything to boot!).
In addition to working for hard disks, this procedure also works for SCSI removable-media devices (such as Zip and Jaz drives) that contain BSD disklabels.
unknown vendor 0x200d product 0x00c2 (class prehistoric, unknown subclass 0xc2, revision 0x0d) at pci0 dev 0 function 0 not configured unknown vendor 0x200d product 0x00c2 (class prehistoric, unknown subclass 0xc2, revision 0x0d) at pci0 dev 1 function 0 not configured unknown vendor 0x200d product 0x00c2 (class prehistoric, unknown subclass 0xc2, revision 0x0d) at pci0 dev 2 function 0 not configured unknown vendor 0x200d product 0x00c2 (class prehistoric, unknown subclass 0xc2, revision 0x0d) at pci0 dev 3 function 0 not configured unknown vendor 0x200d product 0x00c2 (class prehistoric, unknown subclass 0xc2, revision 0x0d) at pci0 dev 4 function 0 not configured unknown vendor 0x200d product 0x00c2 (class prehistoric, unknown subclass 0xc2, revision 0x0d) at pci0 dev 5 function 0 not configuredand incorrectly recognize the TGA frame buffer as a PCI VGA frame buffer. This is a firmware bug, but unfortunately no official version of the Multia/UDB firmware released by DEC fixes it.
Chris Demetriou <cgd@netbsd.org> has a firmware update floppy image which contains firmware that fixes this problem. Get in touch with him if you need it.